In order for the Sparkplug edge node or device to be useful, it needs to have some kind of logical connection to its underlying system, so that it can expose metrics that reflect the data in that underlying system. How this is done differes from project to project, and is up to your code to provide the actual implementation. We call the connection of the Sparkplug edge ndoe or device to the underlying system a data source connection. Rapid Toolkit for Sparkplug defines the plumbing to your code, i.e. it tells your code when to connect and disconnect the data source, and provides means through which you can report successful and failed connections, and disconnections. You can also influence the conditions under which the data source is connected.
In Rapid Toolkit for Sparkplug, each edge node and each device conceptually has its own data source, and the toolkit provides means for your code to define when and how the data source is connected and disconnected. You can completely ignore this mechanism and control the communication with your underlying system in your own way. Using the mechanism provided by the toolkit, however, allows to implement some useful features, such as connecting to your data source only when the edge node or device is actually publishing the data.
A Sparkplug device publishes Birth and Death messages to indicate its status to the Sparkplug system, and provide initial data and metadata of its metrics. Rapid Toolkit for Sparkplug takes care of publishing the Birth and Death messages automatically, making sure that the correct sequence is always followed. For example, the devices cannot be "born" unless their parent edge node is online, and the edge node Birth message must be published first, and only then the device Birth messages can follow.
In Rapid Toolkit for Sparkplug, the device Birth message is published when the parent edge node is online, and the data source for that device successfully connects. The device Death message is published when the data source for the device disconnects. The lifecycle of the device data source is thus always tied to the device birth and death.
In some cases, you may have a design which requires the Sparkplug device to publish some of its metrics even when there is no communication with physical device (that the Sparkplug device represents). This can be resolved in two ways:
Data publishing by the edge node or device only takes place when its data source is connected. Your implementation needs to define what that means - and how the actual connections to and disconnection from the data source are performed. The behavior can be defined by hooking events handlers or overriding virtual methods. If you do not define it, the default behavior is that the data source connection is a "no operation" and it always succeeds.
You define how to connect to the data source by handling the ConnectDataSource Event on the edge node or device, or by overriding its OnConnectDataSource method. If the event is handled, your code is expected to attempt to connect to the data source (for example, a database or a PLC) and call either the DataSourceConnectionSuccess Method (for success) or the DataSourceConnectionFailure Method (for failure). This can be done synchronously (while handling the event) or asynchronously (e.g. by using a task or a thread). If the event is not handled, the data source is considered immediately successfully connected. Therefore, if you do not need an extra code to connect to your data source, you can rely on this default behavior and not handle the event at all.
You define how to disconnect from the data source by handling the DisconnectDataSource Event on the edge node or device, or by overriding its OnDisconnectDataSource method. If the event is handled, your code is expected to disconnect from the data source (for example, a database or a PLC) and call the DataSourceDisconnectionSuccess Method (the disconnection must always "succeed"). This can be done synchronously (while handling the event) or asynchronously (e.g. by using a task or a thread). If the event is not handled, the data source is considered immediately successfully disconnected (as if your code had called the DataSourceDisconnectionSuccess Method). Therefore, if you do not need an extra code to disconnect from your data source, you can rely on this default behavior and not handle the event at all.
The following example illustrates a custom data source connection handling, with a connection that sometimes succeeds and sometimes fails.
The data source connection mode defines when and how the Sparkplug producer (edge node or device) connects and disconnects its data source. You can configure the data source connection mode using the DataSourceConnectionMode Property on the edge node or device object.
The choice of the data source connection mode depends on the nature of the implementation. The usual default setting (WhenComponentStarted) attempts to maintain the connection to the data source for the widest possible time. This means that you can e.g. keep collecting the data from the data source even when the connection to the MQTT broker is not available, store the data and publish them later. If you do not have this or similar requirements, you can consider choosing a "narrower" data source connection mode.
Following choices are available for the data source connection mode:
The example below connects the data source (and publishes data) only when the producer is online (with no primary host application set, this means that it connects to the data source only when it is connected to the MQTT broker).
Sparkplug is a trademark of Eclipse Foundation, Inc. "MQTT" is a trademark of the OASIS Open standards consortium. Other related terms are trademarks of their respective owners. Any use of these terms on this site is for descriptive purposes only and does not imply any sponsorship, endorsement or affiliation.